I just tested this locally, since I build local ARM versions I'd have to remember to add --pull=false to test things I am building locally. Is it as this point we add a dependabot config command to set ~/.dependabot configurable defaults?

No, that's going to add too much complexity IMO. I'll have to do:

I've updated this PR to compare digests first, instead of just blindly pulling the latest container.

Smoke test failures appear to be unrelated to my changes.

With the timestamp check this breaks my local workflow unless I add --pull=false. To debug issues usually once a day I do:

$ cd dependabot-core
$ script/build go_modules

Sometimes this is just main, but also I'll make modifications locally to help debug.

Then I'll run dependabot update ... for the rest of the day. It would be very confusing if it downloaded a newer version without me noticing.

I'm thinking a better approach would be to first see if a local image is custom by asking the registry if it has that SHA. If an image with that SHA doesn't exist, then don't automatically pull. If it has seen it that would indicate it's ok to pull the latest.

I do like this idea as a feature as we've seen folks confused that they need to update their local images occasionally.

@jakecoffman I think I've addressed your concerns. The CLI will now check to see if the digest exists remotely. If yes, it will proceed to check if the digest is the latest for the current tag. If no, it will continue with the local digest and avoid the remote registry check.